Magnum One

home *** CD-ROM | disk | FTP | other *** search

/ Magnum One / Magnum One (Mid-American Digital) (Disc Manufacturing).iso / d20 / xrdor200.arc / XRDOR200.DOC < prev next >

Wrap

Text File | 1991-05-05 | 46.3 KB | 898 lines

XXX XXX RRRRRRRR SSSSS <tm> XXX XXX RRR RRR SSS SS XXXXXX RRR RRR SSS XXXX RRRRRRRR SSS DDDD OOO OOO RRRR XXXXXX RRR RRR SSS D D O O O O R R XXX XXX RRR RRR SS SSS D D O O O O RRRR XXX XXX RRR RRR SSSSS DDDD OOO OOO R R RemoteAccess/QuickBBS/SuperBBS eXpress Door Version 2.00 Program CopyRight (C) 1989, 1990, 1991 by Mike Ratledge Documentation written and all rights reserved by Ed Meloan of 360/1 ┌─────────────────────────────────────────────────────────────────────────────┐ │ ▒▒▒ XRSDoor ▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒ PAGE 1 ▒▒▒ │ └─────────────────────────────────────────────────────────────────────────────┘ ┌─────────────────────────────────────────────────────┐ │ ▒▒▒▒▒▒▒▒▒▒▒▒▒▒ Table of Contents ▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒ │ └─────────────────────────────────────────────────────┘ What is XRSDoor ............................. 2 Getting Started ............................. 3 Setting Up XRSDoor for QuickBBS/SuperBBS..... 4 Setting Up XRSDoor for RemoteAccess ......... 5 Processing INBOUND Mail ..................... 7 Setting Up The QMXSETUP.CFG File ............ 8 A Few Hints ................................. 12 A Short Check List .......................... 13 Using XRSDoor on Your BBS ................... 13 XRSDoor User Requests ....................... 15 Odds & Ends ................................. 17 Credits ..................................... 19 ┌─────────────────────────────────────────────────────────────────────────────┐ │ ▒▒▒ XRSDoor ▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒ PAGE 2 ▒▒▒ │ └─────────────────────────────────────────────────────────────────────────────┘ ┌─────────────────────────┐ │ ▒▒▒ What is XRSDoor ▒▒▒ │ └─────────────────────────┘ XRSDoor is An exciting way for your callers to get all the messages they are interested in and =READ THEM AFTER THEY LOG OFF=. The XRSDoor system allows your users to do the following: 1. Custom select the Message Areas =THEY= want to read 2. Collect the new messages from these areas =AND= ALL messages addressed to them even in areas they don't select. 3. Pack them in an archive and send them to their computer 4. Lets your user read them while off-line, freeing your board for the next caller!! 5. The companion XRS Response system gives your caller an EXCELLENT full-screen editor that allows them to read, reply and edit all their messages WHILE OFF-LINE! 6. Pack their replies and send them back to this BBS where XRSDoor will automatically place them in the correct message areas just as if the user had written them there. ┌─────────────────────────────────────────────────────────────────────────────┐ │ ▒▒▒ XRSDoor ▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒ PAGE 3 ▒▒▒ │ └─────────────────────────────────────────────────────────────────────────────┘ ┌─────────────────────────────────────────────────────┐ │ ▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒ Getting Started ▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒ │ └─────────────────────────────────────────────────────┘ Read the following information and you'll be on your way to providing your RemoteAccess/QuickBBS/SuperBBS users with this exciting new feature! If you're already running ECHOMAIL - then you are well on your way already! Since XRSDoor depends on an AREAS.BBS file to know where to place incoming messages, you'll need to have that file set up. One point here is that you =MUST= setup names for EVERY message area... Even ones which normally do not handle ECHOMAIL. This allows your present echomail processing to properly toss LOCAL as well as ECHO messages into the correct message areas. [A note here that while XRSDoor can handle AREAS.BBS area names in lower case, some mail tossers can not! All area names should be in UPPER CASE.] The XRS program requires group zero to be a local message area, and therefore XRS always shows "00 LOCAL" as the first available group. This 00 area is inherited from the TCOMM program, for which XRS was originally written, and really has no function in the R/Q/SBBS environment. You should setup the main general local area of your BBS with the area name "LOCAL", so that the mail tosser will place the inbound traffic into the correct area. This can be ANY message area number as long as it is named LOCAL in AREAS.BBS. Since there is no 00 area, as there is in TCOMM, you will want to use one of your regular area numbers. This feature is required because all your users may not have access to NetMail - they cannot send private message back to your BBS (XRS will =ONLY= allow private status on NetMail, Local or in response to a private message)! XRS version 4.0 and later =DO= recognize areas which have either private or "both" access, so those areas can have private messages, too. ┌─────────────────────────────────────────────────────────────────────────────┐ │ ▒▒▒ XRSDoor ▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒ PAGE 4 ▒▒▒ │ └─────────────────────────────────────────────────────────────────────────────┘ ┌────────────────────────────────────────────────────┐ │ ▒▒▒ Setting Up XRSDoor for QuickBBS/SuperBBS ▒▒▒ │ └────────────────────────────────────────────────────┘ XRSDoor is compiled in TWO versions. Select XRSDoor.EXE for use on XT (8088) systems and XRSDoor!.EXE for V20/80286/80386 systems and place the correct version in your QuickBBS/SuperBBS system directory. XRSDoor must be set up as a Type 15 external program. It will NOT work as a type 7 option. Here are the steps to set XRSDoor up as a type 15 menu option: Decide on an error level and add the following lines to your QuickBBS or Mailer BAT file. Let's assume we decide to use 98 as our level. We would set up a type 15 menu option with 98 as the optional data. Do not type the comments that are in brackets. For SuperBBS "SET SUPER=Y" in the environment. :After_Quick If errorlevel 98 goto XRSDoor (ADD this line) If errorlevel 5 goto Both (You probably already have this line) If errorlevel 4 goto NewEcho ( " " " " " " ) If errorlevel 3 goto NewNet ( " " " " " " ) Goto Loop (or whatever you call your starting section of BAT file) Since XRSDoor has its own internal FOSSIL handling and carrier detection, you will not need nor should you use redirection devices such as CTTY or GATEWAY or carrier monitors such as WATCHCD. Please =DO NOT= use them. All you will need in your BAT file will be something like this: :XRSDoor XRSDoor!.EXE (or XRSDoor.EXE) QuickBBS -R -E0 Goto After_Quick ┌─────────────────────────────────────────────────────────────┐ │ ▒▒▒▒▒▒▒▒▒ TWO IMPORTANT NOTES !! ▒▒▒▒▒▒▒▒▒ │ └─────────────────────────────────────────────────────────────┘ You =MUST= have the popular archiving programs PKARC, PKZIP, and LHA as well as a recent version of ZMODEM (DSZ.COM) AVAILABLE FROM YOUR PATH!! We cannot emphasize this too strongly. Having them in the QuickBBS sub-directory is not necessarily enough if you don't have that sub-dir in the path statement! XRSDoor uses DSZ.COM to provide external protocol support. It does not select the COM: port for DSZ! If you use COM2: (or anything other than the default COM1: address) you must place the following command immediately before XRSDoor in your batch file: SET DSZPORT=2. "SET SUPER=Y" selects SuperBBS support. SET DSZPORT=2 would tell DSZ to use COM2:, for example. You should also place a similar command after XRSDoor without the '2' (but no spaces after the '=' either!), and you will free up the environment string space it uses. ┌─────────────────────────────────────────────────────────────────────────────┐ │ ▒▒▒ XRSDoor ▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒ PAGE 5 ▒▒▒ │ └─────────────────────────────────────────────────────────────────────────────┘ ┌─────────────────────────────────────────────────────────────┐ │ ▒▒▒▒▒▒▒▒▒ Setting Up XRSDoor for RemoteAccess ▒▒▒▒▒▒▒▒▒ │ └─────────────────────────────────────────────────────────────┘ XRSDoor is compiled in TWO versions. Select XRSDoor.EXE for use on XT (8088) systems and XRSDoor!.EXE for V20/80286/80386 systems and place the correct version in your RA system directory. Complete file sharing and record-locking for updates is enabled *if* DOS "Share" is detected. Assuming Share is detected, XRSDoor looks for "TCNODE" in the DOS environment to determine the node number the user is on (i.e. "SET TCNODE=2" for node 2, etc), and then uses BAT2MAIL.XRS, MAIL2IDX.XRS, SUMMARY2.XRS, USER2.XRS & AREAS2.XRS, all of which get archived into the file BAT2MAIL.* unless it's a local SysOp logon and 'SysOpOut' is in affect. If you run multi-line RemoteAccess, you *must* start the program from the proper \RA\LINEx (or whatever you call them) sub-directory. It is NOT necessary to duplicate the files used by XRSDoor in each line's directory. Here's why... XRSDoor checks for the "RA" set in the DOS environment, and if found, looks in that subdirectory for the CONFIG.RA file. Assuming "RA" is set, XRSDoor uses that file plus the MESSAGES.RA. It then uses the path found in CONFIG.RA to find the message databases. The following files are looked for in the current sub-dir, then in the System Path and finally in the Messages Path. QMXSETUP.CFG, USERS.BBS, EXPRESS.BBS, FLSEARCH.QMX and DOWNLOAD.QMX You can have specialized nodes or let a single set of control files be used. The "QMX_CONF.SYS" file (user defaults) is first looked for in the current sub-directory, then in the System (*not* messages!) sub-directory for RA. This way you can have separate paremeters/configuations and users on each node if you wish, or one configuration stored in the System directory. XRSDoor will look for DORINFO1.DEF and EXITINFO.BBS in the sub-directory where XRSDoor is located and =ASSUMES NODE 1= so single-line systems with Share enabled are not treated like networks and the use of the TCNODE environment variable is only required for true multi-line systems. ┌─────────────────────────────────────────────────────────────────────────────┐ │ ▒▒▒ XRSDoor ▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒ PAGE 6 ▒▒▒ │ └─────────────────────────────────────────────────────────────────────────────┘ Using file sharing and record-locking, multiple users can all access the databases =AND= XRSDoor at the same time. Full support for the "RemoteAccess BBS" software is included. XRSDoor looks to see if RA has been set in the environment and if found, uses the RA Configuration files for information about message area security and access. It also notifies XRS 3.12 and later to tag the tear and origin lines with the proper RAX identity. Please NOTE that although XRSDoor uses the MESSAGE.RA file, it will still need an AREAS.BBS file since the MESSAGE.RA file does =NOT= contain the exact ECHOMAIL AREA NAMES! You do not need a copy of AREAS.BBS in each line's sub-directory since XRSDoor will look in the system and message directories if it doesn't find the file in the current directory. XRSDoor is remarkably simple to setup on the RemoteAccess system. A menu type 7 (shell) works VERY well! Add the *M and you can swap RA out of memory if you are multitasking and memory space is limited. Since XRSDoor has its own internal FOSSIL handling and carrier detection, you will not need nor should you use redirection devices such as CTTY or GATEWAY or carrier monitors such as WATCHCD. Please =DO NOT= use them. All you will need in your menu type 7 OPTIONAL DATA is the following line: C:\RA\XRSDoor!.EXE *M (or XRSDoor.EXE *M) That's it! No elaborate BAT files are needed! Including the C:\RA\ path will allow you to use a single copy of the XRSDoor program, regardless of the number of lines you may be running. If you do NOT put XRSDOOR?.EXE on your PATH, you will need a copy of XRSDoor in the directory for EACH line. ┌─────────────────────────────────────────────────────────────┐ │ ▒▒▒▒▒▒▒▒▒ TWO IMPORTANT NOTES !! ▒▒▒▒▒▒▒▒▒ │ └─────────────────────────────────────────────────────────────┘ You =MUST= have the popular archiving programs PKARC, PKZIP, and LHA as well as a recent version of ZMODEM (DSZ.COM) AVAILABLE FROM YOUR PATH!! We cannot emphasize this too strongly. Having them in the sub-directory with XRSDoor is not necessarily enough if you don't have that sub-dir in the path statement! XRSDoor uses DSZ.COM to provide external protocol support. It does not select the COM: port for DSZ! If you use COM2: (or anything other than the default COM1: address) you must place the following command immediately before XRSDoor in your batch file: SET DSZPORT=2 SET DSZPORT=2 would tell DSZ to use COM2:, for example. You should also place a similar command after XRSDoor without the '2' (but no spaces after the '=' either!), and you will free up the environment string space it uses. ┌─────────────────────────────────────────────────────────────────────────────┐ │ ▒▒▒ XRSDoor ▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒ PAGE 7 ▒▒▒ │ └─────────────────────────────────────────────────────────────────────────────┘ ┌─────────────────────────────────────────────────────────────┐ │ ▒▒▒▒▒▒▒▒▒ Processing INBOUND Mail ▒▒▒▒▒▒▒▒▒ │ └─────────────────────────────────────────────────────────────┘ XRSDoor will attempt TO PUT UPLOADED FILES INTO A NEW SUB-DIRECTORY NAMED \QMX ON THE CURRENT DRIVE. You will need to MAKE A DIRECTORY, off the root, called QMX. You must move the incoming message files, from your users, into your normal inbound net files area for processing by your echomail software =UNLESS= you use MkXRS!. If you choose to use the Mark May utility MkXRS, you will NOT need to move incoming mail from \QMX\ since MkXRS will toss DIRECT from \QMX\. Please see the MkXRS entry in the QMXSETUP section for details on how to set it up. (Using MkXRS offers the additional advantage of allowing you to support RIME and other network software other than FidoNet, too.) XRS now leaves behind only *.PKT files when it is through. If you do NOT use MkXRS you'll need to add the following lines to your BAT file to handle the incoming mail. Place this line so that it is read either before or after every call! If exist \QMX\*.PKT goto XRSMail :XRSMail COPY \QMX\*.PKT \FD\FILES (Replace \FD\Files with YOUR incoming DEL \QMX\*.PKT mail directory) :Toss_Echo (Start of your regular ECHO tossing section) CD\RA (or QuickBBS or FD) Qecho -A -P -T -U (or EchoGen, TosScan or Zmail...) Goto Loop This will copy the new incoming messages into the correct area and then drop through to your regular tossing program. D'Bridge users see page 12. XRSDoor exits with different errorlevels to tell you whether an upload was received and/or mail was downloaded. ErrorLevel = 0 means no errors and neither u/l or d/l was used. ErrorLevel 1 means mail was downloaded, a 2 means mail was uploaded and a 3 means both upload and download of mail. An option is available which allows the user to get their mail, automatically update their "last read" pointer and automatically LOG OFF! Three additional error levels handle this "auto-logoff" function for those who wish to control mail handling through error codes. 4 indicates automatic logoff with no transfer, 5 indicates auto-logoff with a mailbag downloaded and 6 means auto- logoff with both upload and download of mail. (All higher exit codes indicate other program failure of some type!) These error levels can be used to direct specific BATCH file activities if desired. Please note! It is NOT necessary to use these codes unless you wish to do so. RemoteAccess or QuickBBS will recover from the AUTO-LOGOFF without their use and mail will be tossed normally. ┌─────────────────────────────────────────────────────────────────────────────┐ │ ▒▒▒ XRSDoor ▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒ PAGE 8 ▒▒▒ │ └─────────────────────────────────────────────────────────────────────────────┘ ┌────────────────────────────────────────────────────────────┐ │ ▒▒▒▒▒▒▒▒▒ Setting Up The QMXSETUP.CFG File ▒▒▒▒▒▒▒▒▒ │ └────────────────────────────────────────────────────────────┘ XRSDoor allows the SysOp to control certain functions by editing a "configuration" file. This file is named: QMXSETUP.CFG. Here are the options in QMXSETUP.CFG along with brief descriptions of the options function. BBSID xxxxxxx - The "BBSID" parameter is =REQUIRED=! If not found, XRSDoor will still run, but it will beep and display a warning message and use the name "UNKNOWN1" for the BBS name if "Named Mailbags" are turned on by the user. You should set the BBSID parameter to something that will uniquely identify your BBS. For example, Augusta Forum is AGFORUM. XRSDoor will use ONLY the first seven characters and will add the correct extension. If you are running RemoteAccess and using multiple lines, the eighth character will indicate the line the caller was using. Note that this feature is only available to users of XRS 3.21 and later, and it must be turned on in the new "Option Toggle" section by any user that wants the "Named Mailbag" feature. Named Mailbags =ARE= the default for =NEW USERS=. NetMail xxx - !!REQUIRED!! for RemoteAccess systems. Where 'xxx' is the area number of the netmail board (your main netmail board if you have more than one). Failure to set this parameter for RA dystems causes RA/QMX to beep and use area # 201 as the netmail area (which doesn't exist), therefore any netmail will be treated as echomail! Not needed for QuickBBS/SuperBBS. InDir xxxxx - Allows you to give a different path for incoming mailbags (default is "\QMX"). This is mostly to allow you to accept mail for multiple nodes into separate areas if you also have the "Point xxx" parameter (which causes everyone to have similar filenames). NOTE! Multi-node user =MUST= have a different inbound directory for =EACH= Node! (\QMX1, \QMX2, etc.), and these subdirectories =MUST= be exclusively for use by XRSDoor (empty). To do this, you will need a copy of QMXSETUP.CFG in each line's directory. PointNet xxxxx - Allows you to select the point number used by XRS. By default, XRS uses pointnet number 30027, which was assigned to the program by the ZC/IC. ShowBar - Forces the status bar to be shown even if Desqview is detected. NoBeep - Turns off beeps on SysOp side. OutPath x:\path - Allows you to have XRSDoor automatically place the resulting BAT1MAIL.xxx archive file into a different subdirectory. The "X:\PATH" portion *MUST* point to a directory name! (you can't change the final filename, anyway). You should DELETE this file automatically at logoff time to prevent users from reading someone else's mail. ┌─────────────────────────────────────────────────────────────────────────────┐ │ ▒▒▒ XRSDoor ▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒ PAGE 9 ▒▒▒ │ └─────────────────────────────────────────────────────────────────────────────┘ ┌────────────────────────────────────────────────────────────┐ │ ▒▒▒▒▒▒▒▒▒ Continuing the Setup of QMXSETUP.CFG ▒▒▒▒▒▒▒▒▒ │ └────────────────────────────────────────────────────────────┘ SysopOut x:\path - Allows THE SYSOP (User 0) to have XRSDoor automatically place an UNARCHIVED MAILBAG into a different subdirectory. The "X:\PATH" portion *MUST* point to a directory name! NoBuff - Disable file buffering on MSGHDR.BBS and MSGTXT.BBS - on some systems it may be faster to *not* buffer these files! LockBaud - Force Hardware Flow Control on DSZ - required for HST's, etc! ShowFiles - Show New Uploads ON SCREEN during FileScan. Files will ALWAYS be included in the XRS <F6> pop-up Summary if FLEARCH.QMX is present. More on FLSEARCH.QMX later. NoBreak - To disable <CTRL-BREAK/C/K> exits from external batch files, you may use the this parameter. NOTE: The user cannot interrupt the program except by hanging up if this is turned on! Under normal conditions, this option should be left turned OFF! (When left off, the user is sent back to the BBS when he hits <CTRL-BREAK/C/K>...) Point 666 - In order to run in "No Points" mode, or to assign a specific point number to all XRSDoor/XRS users, place a number from 0 up to 32767. For NO points, use 0. If you want XRSDoor to assign the point numbers in consectutive order do NOT use this option at all. Limit 500 - To use a different maximum limit of messages for one mailbag, assign any number less up to 5000. Normally, XRSDoor will only pack up to 995 messages for each user, anyway - they must set the "<O>ption toggle" to allow them to select mailbag size if they want more. Include - Accepts a filename (*with* pathname!) and inserts that file into the mailbags. You can use "wildcards" to insert multiple files if you wish. Show PIDs - Makes the ^aPID: lines show up in the XRS mailbags. [These show up in XRS with XRS version 4.00 and later only!] MkXRS - Causes XRSDoor to IMMEDIATELY call MkXRS after an incoming mail bag is uploaded by the user. Mark May's "MkXrs" program can be used to completely automate all inbound mail processing including netmail accounting and tossing mail directly into the BBS message databases without using your normal echo mailmangler. MKXRS103.ZIP is the current released version - it works equally well on any single or multi-line system, but if you have two or more nodes, you should have separate "inbound" XRS-mail areas. You can call MKXRS automatically after each incoming mailbag is inspected for UserRequests by placing "MKXRS" into your QMXSETUP.CFG file. ┌─────────────────────────────────────────────────────────────────────────────┐ │ ▒▒▒ XRSDoor ▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒ PAGE 10 ▒▒▒ │ └─────────────────────────────────────────────────────────────────────────────┘ ┌────────────────────────────────────────────────────────────┐ │ ▒▒▒▒▒▒▒▒▒ Continuing the Setup of QMXSETUP.CFG ▒▒▒▒▒▒▒▒▒ │ └────────────────────────────────────────────────────────────┘ New Only - Makes the file search show =ONLY= new files - never the five "most recent" which are the LAST five found in each FILES.BBS listing. Defer - Disable the internal DSZ downloads (so user can d/l from normal files area) [NOT NEEDED if OUTPATH is used] NoLogOff - Disables the logoff by carrier drop for systems running XRSDoor under Wildcat. FreeTime xx - Since XRS Door supports file-requests, it is unlikely that most SysOps will want to continue "*!" free time. A new QMXSETUP.CFG parameter allows you to give users 'x' minutes of free time - "FreeTime 20" will add 20 minutes to the available time in the door. NOTE HOWEVER, that you most likely still need to add "*!" to the command-line on the menu, or the BBS software is liable to terminate the door when time would have normally run out! That way, the BBS thinks the user has unlimited time, but actually, they get no more than the remaining time (plus "Freetime" extra minutes if you specify any). XRSDoor =ALWAYS= calculates the maximum number of messages which a user at any specific baud rate can get in the remaining time and adjusts the maximum count down if they would exceed the time limit! Force xxx - You can force users to read a certain area on your board by placing a new parameter "FORCE xxx" where 'xxx' = the area *number* you want to be required reading. Note that XRSDoor doesn't tell the user it is forced nor display it as part of his list (unless he already selected it), nor will turning the area off (as many times as he wants <grin>...) work. There can be up to ten of these in your config file. IMPORTANT NOTE: IF YOU TURN ON A CONFERENCE WITH "FORCE" ALL READ SECURITY IS IGNORED! (but if the user doesn't qualify for write access, they cannot reply). Remember - this takes an area *number* as the argument - not a name. Lockout xxx - The same way you can "Force xxx" (where 'xxx' = area number) areas on, you can "Lockout xxx" up to ten areas. ┌─────────────────────────────────────────────────────────────────────────────┐ │ ▒▒▒ XRSDoor ▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒ PAGE 11 ▒▒▒ │ └─────────────────────────────────────────────────────────────────────────────┘ ┌────────────────────────────────────────────────────────────┐ │ ▒▒▒▒▒▒▒▒▒ Continuing the Setup of QMXSETUP.CFG ▒▒▒▒▒▒▒▒▒ │ └────────────────────────────────────────────────────────────┘ Swap - Swaps to LIM or Disk (current drive and sub-directory using the filename "SWAP$RQS.!!!") if "SWAP" is in your QMXSETUP.CFG file. XRS swaps the (less than) 116K memory it uses minus a 4K reloader 'stub' on disk if 112K of LIM/EMS memory is not found. Swapping is used for all external program calls including DSZ.COM, MKXRS.EXE and archival programs. Swapping to LIM/EMS is instantaneous, disk swapping is relative to disk performance but hardly noticable even on the slowest hard drive, since XRSDoor doesn't have a large 'footprint'. Allowing "Swap" is definitely most useful for multi-node setups running under DesqView, for example. No EMS - If you do not want XRSDoor to swap to LIM/EMS (use disk only), put the "No EMS" parameter into QMXSETUP.CFG to avoid LIM/EMS swapping. This is useful only in combination with "Swap". (note: if you do not have any EMS memory, this parameter is not needed - XRSDoor will not try LIM/EMS...) The only reason I can think of that you might need this is if your LIM/EMS is not working properly, or you are running a multi-tasker and don't want XRSDoor to tie up that memory even temporarilly. If you have LIM/EMS but do not have enough free, XRSDoor will swap to disk instead automatically. ┌─────────────────────────────────────────────────────────────────────────────┐ │ ▒▒▒ XRSDoor ▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒ PAGE 12 ▒▒▒ │ └─────────────────────────────────────────────────────────────────────────────┘ ┌────────────────────────────────────────────────────────────────┐ │ ▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒ A Few Hints ▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒ │ └────────────────────────────────────────────────────────────────┘ XRSDoor looks for FLSEARCH.QMX - if not found *NO* "New File Search" is done at all! This way you can just search one or two if that is what you want, or you can turn it off altogether. If you want it to search all areas, just "COPY FLSEARCH.CTL FLSEARCH.QMX". (the format of the file is *exactly* like FLSEARCH.CTL!) If you do not want to search ALL areas, simply copy FLSEARCH.CTL to FLSEARCH.QMX and then edit out the lists you do not want included in the search. You can also automatically restrict the user-side program (XRS) from sending any mailbags in formats you can't process by placing a file named ARC_ONLY.XRS (or ZIP_ONLY.XRS, but not both!) into the system subdirectory. When XRS sees this file it will only use the desired method to pack the mail. You may "Force" your users to use YOUR origin line if you like. To do this just create a file called XORIGIN.XRS which contains the desired line in plain ASCII. If XORIGIN is present, XRSDoor will place a CRC value in the users file which can be read by XRS version 3.12 or later. This CRC check will not allow the user to replace YOUR line with one of his own. A CRC check is also performed on the users name. If either are incorrect XRS will terminate immediately, assuming that you must have a problem user hacking the files! XRSDoor recognises the person named in DORINFO?.DEF as the SysOp and always allows *CRASH* netmail for THAT person. The XRUSERED User Editor will also allow the SysOp to designate users who may send crash mail by setting the crash option, for designated users, with the User Editor. If you are a D'BRIDGE user: XRSDoor normally puts all files in a directory named \QMX. Assuming that your inbound mail goes to a directory named \QUICK\MAIL, add the following to your BBS.BAT file. You may put it after an exit from the BBS or at the beginning of the batch file if you restart it after each user. if exist \qmx\*.PKT goto qmxmail :qmxmail copy \qmx\*.PKT \quick\mail echo y | del \qmx\*.* cd \dbridge db unpack At this point, you need to return to the beginning of the batch file, or wherever else you run DB as your mailer. ┌─────────────────────────────────────────────────────────────────────────────┐ │ ▒▒▒ XRSDoor ▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒ PAGE 13 ▒▒▒ │ └─────────────────────────────────────────────────────────────────────────────┘ ┌────────────────────────────────────────────────────────────────┐ │ ▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒ A Short Check List ▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒ │ └────────────────────────────────────────────────────────────────┘ Here's a short check list of what we have done. 1. Make sure ALL message areas are listed in AREAS.BBS 2. Create at least one "inbound" directory called \QMX OFF THE ROOT, NOT OFF the QuickBBS or RA subdirectory! ^^^^^^^^^^^^ 3. Add a Menu option to allow your users to access XRSDoor 4. If QuickBBS, add the necessary lines to your BAT file to handle a Type 15 menu option exit. If RemoteAccess, add a type 7 menu option as shown in the RA section. 5. Add the necessary lines to MOVE incoming XRSDoor mail to your ECHO tossing directory or setup MkXRS to handle mail tossing (MkXRS recommended!!). 6. Edit QMXSETUP.CFG and place it and XRSDoor.EXE in the system directory. If running multiline, place a copy of QMXSETUP.CFG in each line's sub- directory and use a DIFFERENT inbound (\QMX1, \QMX2, etc) command for each line. 7. Make a copy of FLSEARCH.CTL and name it FLSEARCH.QMX =IF= you want new files listed. Place it in the system directory. ┌────────────────────────────────────────────────────────────────┐ │ ▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒ Using XRSDoor on YOUR BBS ▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒ │ └────────────────────────────────────────────────────────────────┘ Important! Your caller MUST have a CONFIG.SYS file setup on their system with a FILES equal AT LEAST 20! Failure to do this will cause the XRS program to be unable to unpack mail. If a user complains about this problem, that should be the first thing you ask about. They should also download a small mailbag BEFORE running XRS the first time. XRS will look for mail and complain if it can't locate any! (this also can cause the program not to "see" other files that *are* there...) Your callers will find running XRSDoor basically intuitive. The first time your user goes into XRSDoor they will be asked to select their default message areas to read, the message packing method and transfer protocol to be used. Message area selection must be done before the caller can "Pack for Download". Unconfigured (new) users are not given the option to download messages UNTIL they have completed their configuration. ┌─────────────────────────────────────────────────────────────────────────────┐ │ ▒▒▒ XRSDoor ▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒ PAGE 14 ▒▒▒ │ └─────────────────────────────────────────────────────────────────────────────┘ When selecting message areas the first time, your users should select from "All" groups instead of only those which have new messages! This will allow them to select from all available groups and save these defaults for use every time until they change them (and not miss any areas that do not have "new" messages available at the current time). The users SECURITY level and AUTHORIZATION flags determine the areas from which users can read or write. If a message area has a higher security level in READ the user will be unable to select that area to be included in their mailbag. If the area's security allows the user to read but not to write in an area, XRSDoor will allow the reader to read but will not allow a reply to a message or a new message to be written in the area. The number of messages XRS can handle in one "MailBag" is unlimited, but 5000 is the maximum number of messages XRSDoor will extract before beginning the archiving process - normally, a caller will probably get much less mail than that! XRSDoor will normally default to a number that gives the LAST 20% of the messages FOR A FIRST TIME USER. This prevents a first time caller from accidentally downloading a packet of ALL the messages! As Sysop, you can set the maximum limit higher or lower than 995 by using the LIMIT option in your QMXSETUP.CFG file. (XRS 4.11 or higher is required for > 995 messages) Note that XRSDoor (and the XRS reader/editor) do not do "exact" matching as far as upper/lower case letters go! You will always get all messages addressed to you no matter how the names are capitalized by the sending system! Unless instructed not to, XRSDoor will ALWAYS automatically extract =ALL= mail addressed to the caller whether or not they have the message's group selected. That way, the caller can be assured that they won't miss any mail even if they don't regularly read certain conferences. This function can be defeated by selecting an option in the XRSDoor configuration section. The user may elect to tell XRSDoor =NOT= to scan for messages OUTSIDE the selected areas. This change is useful if the user calls several boards and doesn't want to receive duplicates of the same messages from each board. XRSDoor will NOT extract messages FROM the caller since it assumes they have seen them before! Your user CAN include their own messages by selecting that option in the CONFIGURATION OPTIONS menu. XRSDoor allows a caller to select message areas that have PRIVATE messages. When scanning these areas, it will =ONLY= pack mail addressed TO THE CALLER OR MARKED "Public". Private mail to other individuals is NOT included in the mailbag. XRSDoor will normally ask if you wish to update the HighMsgRead and/or LASTREAD.BBS fields, assuming you read new message (you can select "Pack" from the main menu and "backtrack" to old messages!). You should, in general, always answer "Yes"! If your user selects the <Q>Uick logoff option, when packing mail, then the High Message Read fields are updated automatically. ┌─────────────────────────────────────────────────────────────────────────────┐ │ ▒▒▒ XRSDoor ▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒ PAGE 15 ▒▒▒ │ └─────────────────────────────────────────────────────────────────────────────┘ ┌────────────────────────────────────────────────────────────────┐ │ ▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒ XRSDoor User Requests ▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒ │ └────────────────────────────────────────────────────────────────┘ XRS Door supports "UserRequests" which include both an AreaFix-like capability and the ability to "psuedo-FileRequest" from the BBS (i.e. automate the download of files by sending a message). WARNING! IN ORDER TO SUPPORT THIS, XRS MUST HAVE A "PRIVATE" SUBDIRECTORY FOR EACH NODE YOU HAVE, TO PROCESS INBOUND MAIL AND "CLEANSE" THE MAIL OF MESSAGES ADDRESSED TO 'XRS' (the UserRequests). FAILURE TO HAVE AN EMPTY SUB-DIRECTORY AT THE STARTUP OF UPLOADS TO XRS DOOR COULD POTENTIALLY GO INTO A LOOP TRYING TO PROCESS SOMETHING THAT IT THINKS IS MAIL. XRS DOOR ONLY EXTRACTS *.PKT FILES FROM USER-UPLOADED MAILBAGS (OR WILL USE "NAKED" *.PKT FILES FROM NON- MSDOS USERS), AND NUKES THE REST, SO THERE IS NO WAY FOR A "MAIL BOMB" TO GET BY! (this is the same \QMX - or "InDir xxx" subdirectory you already setup!) SysOps have total control over User File Requests - a new file "DOWNLOAD.QMX" which uses the same format as "FLSEARCH.QMX" allows for greater flexibility by bypassing the normal methods, which would allow SysOps to define only certain areas as being requestable via XRSDoor. This way you can allows downloads from areas which are not normally scanned for "new uploads", too. If the "DOWNLOAD.QMX" file is not found, "FLSEARCH.QMX" is used instead. To create User Requests, XRS users simply address a message to "XRS" with requests in the text portion of the message. All forms of requests can be mixed and matched in a single message, and multiple messages per session are allowed as well (for now the subject is ignored). Each request must be placed on a separate line! Each line is checked and interpreted as follows: If a '.' character is found, the line is always interpreted as a User File Request, the areas in DOWNLOAD.QMX (or FLSEARCH.QMX if no DOWNLOAD.QMX file exists) for which the user is eligible are each searched serially until a matching file is found, then the file is sent using the selected file transfer protocol (with Z-Modem auto-download, all of this could be easily automated!); otherwise, a User Message Request is assumed and the program looks through the tables trying to match either the AREA: tag _or_ the SysOp-defined 'topic' of the area or if the request is numeric, turns on that area number. Using the area number is the easiest method. A request to turn an area off is preceeded with a minus sign. Wildcards and paths are not allowed! If any user requests are found, a new *.PKT file is built without those messages. Note that the "LOCAL" (area 0) should be used for User Requests, but XRSDoor intercepts, interprets and removes them from any message area. Version 2.00 of "XRSDoor" recognizes the "`" as an "escape" character for area requests, to force XRSDoor to process it even with a period in the echo area name (like "comp.pc.prog.c" or whatever) - see examples on next page. ┌─────────────────────────────────────────────────────────────────────────────┐ │ ▒▒▒ XRSDoor ▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒ PAGE 16 ▒▒▒ │ └─────────────────────────────────────────────────────────────────────────────┘ Some examples of User Request lines in an XRS message: -Dr_Debug C Programming Echo SOMEFILE.ZIP *.ZIP C:\RA\USERS.BBS XRS450AT.ZIP 78 NEW_ECHO `comp.pc.biz The first one would turn off "DR_DEBUG" echo (note - upper/lower/mixed cases are equivalent, and leading spaces are ignored). The second one (assuming the SysOp named C_ECHO "C Programming Echo") would turn on an area, the third line would search DOWNLOAD.QMX for available areas, and attempt to find a matching file to send in them - it would send it with the user-selected protocol automatically if found. Both the fourth and fifth requests are invalid - if any of these characters ('?', '*', ':', '\') are found a file request is ignored. The next request would send the file XRS450AT.ZIP if it is found in an eligible area. Next, there is an example of a numeric message area request - assuming area # 78 is available to you, it would be turned on. The next to the last one would turn on an area named "NEW_ECHO" assuming it was found and the level and access flags check out, and the last one uses the "`" override to turn on an area with a period in the AREA: name (typical in uucp conferences). ┌─────────────────────────────────────────────────────────────────────────────┐ │ ▒▒▒ XRSDoor ▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒ PAGE 17 ▒▒▒ │ └─────────────────────────────────────────────────────────────────────────────┘ You will want to make the XRS eXpress Response Reader available to your callers. The Reader comes with it's own documentation included in the package. Again, there are two versions. One for XT type machines and one for AT systems. Current versions are XRS413XT.ZIP (generic 8088/8086) and XRS413AT.ZIP - the V20/30/80286/386 edition, although version 4.50 is scheduled for release within two weeks of this writing. Overlay versions are also available. Overlay versions require less memory but will not run as quickly on slower machines unless they have LIM/EMS or XMS 2.0 RAM. XRS4CORE.ZIP provides other files needed for ALL versions and =IS REQUIRED= to use XRS. XRS4xDOC.ZIP contains the documentation and several XRS4KIT?.ZIP "ToolKit" files provide sample scripts for various communications programs plus foreign language support overlays and are optional. XCSxxx.ZIP contains Rudi Kusters' "eXpress Conversion System" which allows greater flexibility! ┌───────────────────────┐ │ ▒▒▒ Odds & Ends ▒▒▒ │ └───────────────────────┘ XRSDoor operates as a pseudo-point system. The callers "point" number is determined by XRSDoor the first time the user selects any options in the configuration menu of XRSDoor. The user will be assigned the next consecutive number above the last assigned XRSDoor user. The information that XRSDoor needs for each user is kept in a small file named QMX_CONF.SYS. Since XRSDoor maintains its own data file, you can sort and pack your userlog at any time without any effect on XRSDoor. A XRSDoor User editor program is included. (XRUSERED.EXE) This program will allow you to list your point users and their assigned numbers, and make changes in their configurations. XRSDoor also places information about how many messages are downloaded, mailbags received, groups selected and other information in your LOG file. As a point of information, XRS uses 30027/xxx as the "From" address in the outbound message bundles. This has NO effect on your systems actual node number and can be ignored! ('xxx' always = 0 if running "No Point" mode) Be sure to add "PointNet 30027" to your echomail processor's configuration file if you run in 'secure' mode! This pseudo "PointNet" number was (and other pointnet numbers are) assigned by the Zone Coordinator. XRSDoor watches the users input and features an automatic user entry timeout set at three minutes. This is integrated in the FOSSIL input routines. After two minutes with no activity, the program will beep three times signaling that it is waiting for input. If another full minute elapses without any response, the program is terminated. XRSDoor looks for the file named "EXPRESS.BBS" and copies it into the top of SUMMARY1.XRS each time the program is run. This allows you to have a custom BBS "banner" of special message that will pop up in the users' editor <F6> summary window every time! You should not use color graphics in this file, since the summary routine pokes characters into memory for speed and therefore does not allow for ANSI interpretation... This allows you to have a special announcement capability for XRSDoor/XRS users. You could place notices of new versions being available in there, as well. ┌─────────────────────────────────────────────────────────────────────────────┐ │ ▒▒▒ XRSDoor ▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒ PAGE 18 ▒▒▒ │ └─────────────────────────────────────────────────────────────────────────────┘ The file CURR_VER.XRS (which accepts up to 64 characters) is displayed for all users so they know what the latest version is (of XRS). (sample CURR_VER.XRS included) For RA systems, a single copy of this file should be kept in your "System" subdirectory. A short 'PROMO' file is included, for your use, to announce the addition of RemoteAccess/QuickBBS Message eXpress to your system. You'll find it included as BULLETIN.ASC, should you want to use it in your 'NEWS.ASC' or 'BULLETIN.ASC' files. We think you going to like this new way for your callers to communicate with your system! It allows your best and most active users to get on, get their mail and get off in much less time. If you have questions, suggestions or problems, we'll be happy to help! A FidoNet "EchoMail" conference with AREA: tag "QMX_XRS" is available from the echomail "backbone" system. You'll find lots of friendly help and lively discussion of topics of interest to XRSDoor SysOps in this conference. You should be able to get connected easily via your local Network Echo Coordinator! Note: native Dutch message & help overlays for XRS (Peter Janssen and friends) and Dutch language documentation by Rudi Kusters is available, making XRS truly multi-lingual. French, German and Swedish are also available. If you need one of these for XRS, Contact Mike Ratledge for further details. Using a "Foreign Native Language Support" binary overlay simply involves replacing the standard (English) XRS$ALL.DTA file with another one (written in your own native language), and then XRS will be completely converted to your language. ┌─────────────────────────────────────────────────────────────────────────────┐ │ ▒▒▒ XRSDoor ▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒ PAGE 19 ▒▒▒ │ └─────────────────────────────────────────────────────────────────────────────┘ ┌───────────────────┐ │ ▒▒▒ Credits ▒▒▒ │ └───────────────────┘ Documentation for RemoteAccess/QuickBBS Mail/SuperBBS eXpress module written by: Ed Meloan, Sysop of The Augusta Forum RemoteAccess system (1:360/0, 1:360/1) and Michael Y. Ratledge, dated May 5, 1991. (C) CopyRight 1989, 1990, 1991 by Michael Y. Ratledge, CDP, CSP, SysOp of East Bay X-Change Multi-Node RemoteAccess BBS in Charleston, SC, USA FidoNet addresses: 1/112, 372/0, 372/666, 372/777, 372/888, 372/6666 or Compuserve Information System ID: 76666/1512.